Update 2008-04-24: as commenter Jakub Narebski correctly points out, it should be better to use core.autocrlf and crlf attribute for resolving this issue, but I have had no chance to test this up to now. The solution below is still valid, but more of the sort of an ugly hack.
Update 2008-06-11: I have stopped using this solution and only use “git-config core.autocrlf true” and “git-config core.safecrlf true” any more. It works reliably and is exactly what I need and not such an ugly hack.
Update 2008-06-22: Well, of course you can still get “You have some suspicious patch lines” if you follow the core.autocrlf approach… but this time it really means you have trailing whitespace, not just line-breaks. If you really don’t care about trailing white-space at all, my initial solution is still valid, as it simply disables this check.
If you are using Git under Windows using cygwin, and you got through the initial problems, you will soon realize that Git likes to fail with “You have some suspicious patch lines” when committing.
The cause for this problem is the carriage-return/line-feed problem of Git under Windows/cygwin: The patches contain a trailing line-feed if you edited them with a Windows editor and not strictly inside cygwin. This will trigger the pre-commit hook to fail on patches where the last line of a file has been changed.
To solve the problem, you need to edit .git/hooks/pre-commit and comment out the following lines:
if (/\s$/) {
bad_line("trailing whitespace", $_);
}
Now committing should work.
This info saved my day ! Thanks !
nice
THANK YOU!!!!!!
Thank god for your blog post and Google!
Unfortunately, once I added some files that contained CR-LF, git complains even on “pure UNIX” text files. I practically have to use –no-verify for *every* file now. Looks like Git sucks at having any DOS files in its repository — they seem to get in the way of other files somehow. Git won’t complain over the same files if I create a fresh repository and try to work with them the same way.
Hmm, strange, I cannot confirm this for me here, but maybe I have squelched the error message, I’ll have to check.
Thanks for your comment!
AdSR, You can use the dos2unix to clean up the files which contain the CR-LF.
Git from some time has core.autocrlf and crlf attribute, which should help in mixed UNIX (LF) and Windows (CR LF) environment
Thanks a lot…it does work for me but I never edited the files in the windows based editors… I used the vi in the cygwin…
I don’t understand why some one has to break their head to use a version control system. I have been playing with “git” for the last four days and I am still not able to checkin a file and checkout.
I agree it might be faster working once we master all the tips & techniques of using “git”, but point is why should some one has to master a version control system rather than using it?
I know many people might differ with me.
I partly agree with you, git can be quite hard to learn. But once mastered, you’ll never want to use anything else.
Awesome, I was fighting with GIT over this issue this morning. You win!
Thank you!!
@Martin — I use both git and bzr on a daily basis, and prefer bzr for new projects. git certainly has advantages — particularly on projects with very long histories, where bzr’s performance is presently less compelling — but while it’s head-and-shoulders above the last generation of SCMs (and certainly one of this generation’s best), I don’t think it’s completely settled that git is *the* SCM of this generation.
Anyhow, re a better way to fix this issue…
git-config –global core.whitespace fix
…will trim unexpected endline whitespace, as opposed to just ignoring it. Same syntax for setting core.autocrlf to true if one wants to go that route.
@Charles
I tried your trick and it doesn’t work, however the original one did.
@Russ: I think you should better use
git-config core.autocrlf true
git-config core.safecrlf true
This is what really prevents the problem.
hmm, I actually end up seeing more instances of this error after using
git-config core.autocrlf true
git-config core.safecrlf true
Well, yes, this could of course happen… But this time it really indicates that you have trailing whitespace (not just linebreaks).
If you don’t care about the whitespace, it still is a valid solution to follow my initial advice and comment out the appropriate lines in the post-commit-hook.
I find a better way is to have the pre-commit script chomp CRLF, rather than just ignoring all whitespace. To do this, just add this near the top of .git/hooks/pre-commit:
$/ = “\r\n”; # chomp CRLF
Also, core.autocrlf and core.safecrlf actually convert your CRLFs to LF in the repository. In a lot of cases this is undesirable.
Note that my solution is for people that want and expect CRLFs in all of their files (i.e. using Visual Studio/.NET or whatever). If not, it is trivial to edit the pre-commit script to optionally remove any CRs before looking for trailing white space if expecting a mix of LF and CRLFs.
Specifically, something like this should work:
if (s/^\+//) {
$lineno++;
s/\r//g; # get rid of any carriage returns
chomp;
if (/\s$/) {
bad_line(“trailing whitespace”, $_);
}
…
Setting $/ globally might screw up something else – so this is probably the better option.
thanks for your solution, I had this problem on mac os x leopard and oucommenting
if (/\s$/) {
bad_line(“trailing whitespace”, $_);
}
in .git/hooks/pre-commit solved it
I had this problem as well when I first started using Git, but today I ran into something else.
My requirements are:
o By default I want it to be possible and safe to have files
with arbitrary line ending conventions in the same repository.
In general, I want Git to not modify content (not change line endings).
Put another way, it should just do what I tell it to do
(that may not be what I meant, but that is another issue).
o In order to be able to commit, the pre-commit hook needs to allow
the allowed line-ending conventions. For me, this does it:
if (/\s\r?\n?/) {
bad_line(“trailing whitespace”, $_);
}
Sorry, that should have been
if (/[ \t]\r?\n?$/) {
bad_line(”trailing whitespace”, $_);
}
I don’t want to reject trailing whitespace other than space and tab.
thx, saved my day too :).
Thanks a lot. This was very useful.
Thank you!
The initial solution really works, but as I’m not a big specialist in web-development, let me ask a question: developing with Ruby on Rails – do I need to care about trailing whitespaces?
@Blake
I don’t think it is crucial, but the core.autocrlf and core.safecrlf always works and I see no reason not to use it.
Thx, saved me loads of frastration